…gres.urlSecretName); require encryption key (#331)

* fix(rr): stop agentSandbox externalSecret.name from hijacking postgres; require its encryption key

setting rr.agentSandbox.externalSecret.name (intended for the JWT keypair) silently
(a) routed the agent sandbox postgres connection to that secret's postgres-url key
and (b) coupled the encryption key to it. an existing deployment that just wanted to
reuse its backend postgres crashed at runtime with getaddrinfo ENOTFOUND.

- postgres now only reads from externalSecret when postgres.fromExternalSecret: true
  (default false); otherwise it inherits the backend's config.postgresql connection,
  even when externalSecret.name is set for the JWT
- require the agent sandbox encryption key (validateSecrets, mirroring the JWT keys):
  the proxy derives the sandbox-iframe asset-token HMAC key from AGENT_SANDBOX_ENCRYPTION_KEY
  and throws when serving a sandbox without it (agent_executor/proxy/src/config.ts
  getAssetTokenHmacSecret), so 'optional' would surface as a green pod that fails at
  first sandbox use. fail loudly at render instead.
- updated both validateSecrets fail hints to mention postgres.fromExternalSecret: true
- values.yaml (both copies): add postgres.fromExternalSecret, mark encryptionKey required, note 64 hex
- bump chart 6.11.1 -> 6.11.2; update ci fixtures to supply the now-required encryption key
  and add fromExternalSecret: true to the Option-4 sandbox fixture

* Respect postgres.passwordSecretName in presence of rr.agentSandbox.externalSecret

(cherry picked from commit 38304c0)

* refactor(rr): replace postgres.fromExternalSecret with postgres.urlSecretName

the fromExternalSecret boolean was redundant with the existing Option-3
postgres.urlSecretName/urlSecretKey: 'read postgres-url from externalSecret.name'
is identical to pointing urlSecretName at that same secret (urlSecretKey already
defaults to postgres-url). drop the bespoke flag and the externalSecret postgres
branch entirely, so externalSecret.name covers ONLY the JWT/encryption keys and
never sources postgres.

- remove rr.agentSandbox.postgres.fromExternalSecret (both values.yaml copies)
- postgresUrlEnv: delete the externalSecret postgres branch; move the
  passwordSecretName PGPASSWORD support (#332) into the urlSecretName branch, so
  'DSN from a secret + auto-rotated password from another secret' uses Option 3
- validateSecrets: drop the externalSecret term from $explicitPg; repoint both
  fail hints to postgres.urlSecretName
- ci: test-agent-sandbox-enabled-option uses postgres.urlSecretName (Option 3)
  pointed at its JWT secret instead of the removed flag

* fix(rr): render blobStorage env onto the workflow worker

the agentExecutor / snapshotRetention temporal activities run on the
WORKFLOW_TEMPORAL_WORKER (registered in workflowsExecutor/onpremWorker) and read
snapshot blob storage via getBlobStoreForSnapshots (RR_SNAPSHOTS_* with an
RR_DEFAULT_* fallback). but gitServer.commonEnv was only injected onto the main
backend and the standalone git-server pod, so the worker had no RR_DEFAULT_*
and snapshot blob access failed there -- forcing operators to hand-plumb
RR_SNAPSHOTS_* via env.

include gitServer.commonEnv on the worker when rr.gitServer.enabled (no
git-server host/port split -- the worker is a blob-storage client, not the git
server). self-guards on rr.blobStorage being set, so it no-ops otherwise.

* chore(rr): bump chart version to 6.11.3 (rebased past #333)

---------

Co-authored-by: Ryan Artecona <ryanartecona@gmail.com>